离岸团队的那些事儿 | TW洞见
今日洞见
文章作者来自ThoughtWorks：曲正平，插图来自ThoughtWorks西安Stand-up现场。
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。
交付项目的优与忧
目前，国内的软件公司离岸外包的项目很多，从事软件行业的大多数人都有在这些项目中工作的经历，很多人还是从这些项目开始自己的软件职业生涯。Offshore的项目都有一个特点，那就是跟客户只能远程协作，有的不但有距离问题，甚至工作时间没有任何重叠。如何做好这类项目正在变成一个严肃的话题，因为要做成功一个离岸的项目不但要有硬实力，还需要一些软技能护身。
Offshore的项目相对国内的交付项目，也许离客户较远，没有客户现场无时无刻的压力，加班相对较少，有的甚至完全没有。在这类交付项目的工作体验完全取决于客户的风格，有时候这边的团队会有意无意地去追随客户的一些文化和工作习惯，比如Work From Home。还有，这类团队的规模通常较大，可以产生更好的Team Work，团队成员之间互相备份比较容易，所以请假安排灵活。另外一个优点是有机会去发达国家工作、出差，这绝对是开阔眼界、锻炼自己的好机会。
如果你此刻认为Offshore的项目又有好机会工作起来又轻松，那你就错了。
压力小很可能是一个错觉，这背后有文化背景的原因，国外的客户倾向于勾勒出一个框架，不会跟我们面面俱到，里面的内容需要我们自己去充实，这不像国内的客户那样喜欢整天盯着甚至是项目的细节，貌似要求低实际上要求更高，因为我们要交付的还包括他没有明确要求的东西，如果我们交付的还是一个大体的框架，客户肯定不高兴。而一开始就在内心给自己定位为一个纯粹的交付团队更是不可取的。因为即使是Offshore的项目，我们也需要给客户带去影响力，提供交付的产品本身之外的附加值。
下面让我们从一个项目的长期运行周期来分析一下如何提升跟客户的合作。
在项目的初始阶段，由于销售团队已经给客户做过理念上的灌输，交付团队上手给客户迅速做需求分析，找出痛点，运用我们过人的技术能力和敏捷开发方法让用户很快感觉到我们的优势。然后客户的工程师也因为接触了新鲜事物和得到提升能力的机会，大家情绪都会比较高涨，合作起来也都比较积极，这是我们的蜜月期。
在蜜月期，团队一般会把各种敏捷实践全面铺开，带领所有人按照我们的方式开发产品。如果大家记得扁鹊见蔡桓公的故事，我们一定不会等到问题显现出来再去处理它。在这个阶段大家欢乐之余也要采取一些主动的行动，比如现在流行的客户管理（实际就是管理客户的期望值），客户痛点的深入研究，评估已有系统有需要改进的地方，分析下阶段工作的重点等等。痛点的解决是客户最高兴看到的事情之一，试想一下，任何人看到我们在关注他关注的，他还未来得及关注的下阶段的工作我们都想到了，他能不高兴吗？蜜月期就是蜜月期，即使有些事情没来得及做，在后期仍有改进的机会。
我们现在经常讲同理心，所以我们也要站在遥远的客户的立场上看待我们自己，第一步要清楚客户为什么找到了我们，他们需要从我们这里得到什么，还是要解决他们自己的什么问题？这样才能更好的管理客户的期望值。整个Team的输出是对整个Team的期望值，每个人的输出决定了每个独立的期望值。前者决定了客户的满意度，后者影响了客户的信心。
在蜜月期过去之前我们争取完成以下的任务：
定义优先级，跟客户保持一致 维护一个Priority list，这是一个简单易行的方法，让客户可视，至少保证在双方看到的任务上有相同的认识。
跟客户敲定两边的Team的沟通模式，重点是克服离岸团队沟通效率低和反馈慢的问题 Connection window？追求开发速度和效率。 各角色横向沟通？这样更好的影响客户。 DEV HUDDLE, QA HUDDLE，定期的讨论会。
团队自己能做哪些决定?哪些必须跟客户确认？
制定一个测试策略来保障整个生命周期的软件质量
定期Showcase的时间 定期的Showcase，让客户感受到实实在在的进展，虽然每天早上的Standup都有口头陈述，毕竟Standup只是介绍简单的进度，遇到的问题，以及需要的帮助。每个Standup上客户了解的是一个点，Showcase更像是一条线，是从business的角度完整的展示了团队对客户业务的理解，和团队完成的功能对客户业务的支持。
是否建立Always on video，如果工作时间上overlap比较多的话，一般倾向于有。
对流程控制上达成共同的认识。
项目平淡期
蜜月期过了该怎么办，开始阶段我们的团队帮助客户上马了很多对客户来说很新鲜的东西之后，剩下的就是长期坚持一些实践，时间久了之后难免产生疲劳感。原则性的东西我们还是要坚持，避免虎头蛇尾，这件事情要做好，团队内部口头的承诺是不够的，最好能通过技术手段来保持ThoughtWorks一贯的水准。比如项目要求测试覆盖率不低于80%，我们就需要在提交代码的时候设置这个门槛，达不到要求的代码提交就会被退回来。再者，我们也可以在CI的Pipeline上设置一个性能指标，如果达不到的话，虽然CI可以不去阻止代码的提交，但仍然要生成一个性能调优的Task，之后要尽快把性能调到指标之上。
有规律的Showcase应该是这个阶段交付团队跟客户最重要的沟通了，Showcase表达了两个重要的事情：团队的开发进度和团队对需求的理解。
关于进度，敏捷开发方式其实能够大大加快软件上线的速度，我们靠的是灵活地适应需求变更，适时调整让优先级最高的功能先上线。我们还要靠完善的质量保证，间接的提高交付速度。而不是比拼绝对速度，绝对的速度可能在前期看上去很美，后期产生的技术债会把整个团队推向泥潭之中。对于进度我们可以利用Burn Down / Burn Up chart来标示，从这上面也可以很容易看出交付速度的走势，这样可以提前分析原因并采取一些行动。
对需求要有相同的认识，要达成这个目标，对于离岸交付团队这种远程的合作，推荐更多的使用Wireframe图示来沟通，这样更容易避免偏差，俗话说一个图抵得上一千个字的文字描述。SBE（specification by example）也有异曲同工之妙，多举例子来描述需求也能更好的避免需求的遗漏。
关于需求我还听说过一个故事，讲的是一个卖电钻的公司，老板拿起他们的产品问他的员工，我们卖的是这个电钻吗？员工面面相觑说是，老板说，不，我们卖的是这个，他举起一个带有钻孔的板子，这才是客户需要的。准确的把握客户的需求关注点，转换成客户视角，钻孔的大小，孔径是否平滑这些指标才是客户需要的。
随着对项目的了解的深入，我们需要找到哪些是痛点，哪些是更上一层楼的点，以此选择采取的策略。
随着跟客户的磨合的顺畅，团队对做事方法也争取有相同的认识，比如解决一个问题有多种解决方案的时候，我们是采取根除还是保守治疗？ 不要不好意思向客户寻求帮助，能够帮助到别人真的是一件愉悦的事情。 在这期间我们还需要考虑一个问题：需不需要文档记录沟通的过程？这个太重要了，不要高估了自己或者客户的记忆力。如果以后出现分歧，回溯当时的沟通，至少有免责的功效。 需求的变更是很正常的一件事，团队的任何人都不要把它看成是改正一个错误而有抵触心理。
跟客户一起做回顾会议体现了双方的紧密合作，同时这也是一件有挑战的事情，团队的安全感够不够？
关于这个阶段的建议，最后一个想说的是主动性。中国团队尽可能的“发起”一些讨论会议，增强参与感，而不是仅仅被动的参加一些会议而且发言又不是很积极。主动发起有很多的好处：团队有时间准备一个Agenda或上下文，甚至是一些提前的Spike。而客户则是被动的参与，一切在我们掌握之中，这种感觉是不是很好？
在这个平淡期内，团队需要更高的技巧发出自己的声音，不断的给客户惊喜，哪怕是很小的。
任何组织跟客户的合作，总是要想办法把双方的关系进一步推进到更高的合作级别。我们跟客户合作的级别也决定了我们要采取的策略，和应用的实践，这个方面也需要一个像技术雷达（链接到ThoughtWorks技术雷达）类似的东西来指导我们的工作，让所有的项目都有一个基本的参考。比如对于相对保守敏捷经验不足的客户，我们做重构的时候就要三思，跟客户沟通这些事宜也是同样。本人曾经经历一个项目，在开会的时候一个开发人员说他重构了一个什么什么功能，客户那边炸了锅，我们解释了半天为什么需要做这个，以及我们有哪些保障来确保这些改动不会引进新的bug，但是客户仍然坚持需要执行一个完整的回归测试，即使现在还没有接近下次上线的时间。自此以后我们在说重构的时候，就选择了一个委婉的词汇：Tech Task。
还是同理心，有了它就可以站在客户的视角考虑问题。作为甲方，他的责任是项目的进度是否在正常掌握中。乙方承诺的除了交付的软件本身，是否在影响他们自己的团队的敏捷转型。这是两个大的方面，缺一不可。通过共同合作在交付一个产品的同时，将甲方团队改造成能独立运行的敏捷团队，这其中一定有一些硬性的考核标准。需求变化的响应速度，bug数量是否得到有效控制，持续集成的运行，自动化测试的完善程度，新功能从开始做到上线的时间是否缩短等等。
在日常沟通中，团队对外口径需统一，在任何一个团队成员不确认的时候一定不要给客户答复。技术栈，流程，对各功能的优先级的认识很多方面都可能有这样的问题，所以在团队内部多提前沟通首先达成共识。
项目涅槃期
蜜月期，平淡期过后，“七年之痒”就很可能如约而至。因为随着项目最终交付的临近，任何一个问题在这个阶段出现，都会让人紧张，因为此刻的问题通常维修的成本更高。当我们在这个时期跟客户有分歧的时候，客户说话的分贝数可能会提高，有理有据的说服客户就格外重要。如果此时客户对之前达成的共识或者承诺“忘记了”，我们就可以把之前沟通的邮件、会议记录等东西拿出来。
不要害怕“冲突”。其实在任何时候跟客户进行问题讨论的时候，有意见分歧都是难免的，虽然我们已经装备了软技能这门功夫，也不能完全避免跟客户产生争论。原则性的东西不能退缩，因为没有冲突并不表示我们跟客户达成了一致。虽然经历了冲突，但是争论的问题解决了之后，客户不但会对我们刮目相看，还能促进人与人之间的关系（俗话说不“打”不相识）。
上线临近，大量的defect不能全部修复怎么办？跟客户一起做好Bug Triage，区分好严重的Bug和影响面大的Bug。软件的类型也能影响我们的判断，这个世界上的软件其实只有两种，一种是体验型的软件，一种是工具型的软件，基于这些判断分离出可以不做的工作。放弃一些东西，或者说做减法，需要更高的技巧和系统化的思考。
就像一个好的球员要既能打顺风球又能打逆风球一样，只有打过了逆风球，克服过困难的时期，才能提升心理承受能力，才能从挑战中学习，积累更多的经验，才有资本进一步挑战更高的目标。做项目何尝不是如此。
结语
总的来说如果身处一个离岸项目，团队中的每个角色都要从自己的角度去思考如何去帮助整个团队，每个人都有其自身special的地方，只有这样才能形成合力。即使有On Site的同事在客户那里主持大局，也不能仅仅依赖On Site的同事，过多的依赖会把国内的团队变成一个黑盒，就成为了一个纯粹的外包服务团队。
做离岸交付的项目有苦有乐， 客户的不同和业务的不同会给团队成员们更多的学习机会。当一件事情做多了，会慢慢变成习惯，就像迭代一样，我们需要把它做得越来越好，才能使离岸项目长期的做下去。
回复201501-201512，获取当月精彩洞见合辑
如：想看5月精彩洞见合辑，请回复 201505
若你想去 TW洞见网站阅读所有洞见文章，复制网址在浏览器打开：insights.thoughtworkers.org